A smartcard or chipcard can be a tiny secure cryptoprocessor embedded within a credit card sized card or within an even smaller card, like a GSM card. A smartcard does usually not contain a battery, but power is supplied by a card reader/writer, that is to say, by a read and/or write device for controlling the functionality of the smartcard by reading data from the smartcard or by writing data in the smartcard.
A smartcard device is commonly used in the areas of finance, security access and transportation. Smartcards usually contain high security processors that function as a secure storage means of data like cardholder data (for instance name, account numbers, number of collected loyalty points). Access to these data is only possible when the card is inserted to a read/write terminal.
It is a challenging task to enable integration of a user interface functionality directly in smartcards. For instance, a display may be integrated within a smartcard to display information to a user. Or, buttons may be included in the smart card to allow a user to enter data.
Smartcards were consciously designed without a man-machine interface providing user interaction capability. The lack of support for user interaction reflects both in the hardware design and in the software design (operating system) of known smartcards.
This conscious choice has been driven by the lack of technology for thin, flexible displays and due to strong security requirements posed for smartcards. Nowadays, since the technology for thin, flexible displays is present, strict security rules and procedures make the implementation of user interaction difficult. The introduction of API (application programming interface) known from consumer electronics devices and from personal computer devices is difficult, since security rules require that every system component has to be developed under governance of special procedures, for instance with respect to security and reliability. This requires, when developing or changing any chipcard processor component or software component, a long lasting certification procedure followed by a long lasting process of industry acceptance.
In the following, referring to FIG. 1, a smartcard 100 with integrated display functionality according to the prior art will be described.
The smartcard 100 comprises a plastics substrate 101 on which an integrated circuit is formed which provides the smartcard functionality.
In a security domain or processor 102 (a secure IC processor) of the smartcard, in which a high level of security is provided, a card manager unit 103 (which may be a logical unit, a software procedure running when an Application Protocol Data Unit, APDU, is received) is arranged which is adapted to communicate with a plurality of application units 104 each of which contains data and commands needed for servicing different applications. An operating system 105 is provided containing software for operating the smartcard 100. Further, a plurality of driver units 106 are provided, each for driving an associated hardware unit 107.
The smartcard 100 is designed to communicate with a smartcard read and write terminal 108 as a master. The communication between the terminal 108 and the smartcard 100 is performed via the exchange of Application Protocol Data Units (APDU) according to ISO 7816. The card manager unit 103 exchanges APDUs with a particular one of the application units 104 to carry out a corresponding one of the applications.
The internal structure of the smartcard 100 is similar to a standard (personal computer like) architecture which can be described in the well-known layered model. Looking at the hardware units 107, these units may include processors, memories, peripherals and several encryption/decryption co-processors working directly with low-level drivers. The driver units 106 are forming a part of the Operating System Layer (OSL). OSL provides an abstraction of functions in hardware to applications and provides additional functions often reused by applications. The operating system 105 is also responsible for chip initialization during power-up.
On the top of the operation system, provider specific applications may be run which are shown schematically in FIG. 1 as application units 104. Since smartcards like the smartcard 100 are commonly used with terminals like the smartcard read and write terminal 108, a master-slave like communication behaviour is deployed. This means that the terminal 108 is initiating communication with the smartcard 100 sending Application Protocol Data Units (APDU) to the processor 102. The card manager 103 using address field in APDU may recognize to which application unit 104 it should be forwarded. Addressed application, after reception of that information, executes requested action and in return responds with status/data to the terminal 108. This communication scheme requires that for complex applications, both terminal 108 and smartcard 100 have to store actual state of communication.
Apart from the described components and their function, the smartcard 100 comprises extensions to allow a user interface functionality of the smartcard 100.
For this purpose, in a portion of the smartcard 100 which does not relate to the security domain 102, buttons 112 and a display hardware 113 are provided. In order to allow a user to interact with the smartcard 100 via inputting commands by the buttons 112, there is a connection between the buttons 112 and a display interface unit 111 arranged on the level of the hardware units 107 and in the secure domain 102. Further, a display driver unit 110 is provided on the level of the driver units 106 to allow a user to visually perceive data being displayed on the display hardware 113. In the smartcard 100 shown in FIG. 1, a display functionality or user interface functionality is provided by the displays 113 and the buttons 112. Furthermore, an extension or adaptation of the operating system 105 is necessary, which is shown schematically as an operating system extension 109 in FIG. 1.
The smartcard 100 includes, next to standard blocks shown in solid lines, additional blocks 110, 111, 112, 113 marked with dotted lines. These additional blocks provide the user interface functionality. It can be seen that a new hardware component 111 with a corresponding display driver 110 has been added and the operating system 105 has been extended with functions to provide display functionality API to the applications performed according to the application units 104.
However, the smartcard 100 implementation according to FIG. 1 has some drawbacks.
Firstly, the operating system 105 requires modification in the form of the operating system extension 109. This causes development costs and certification costs. Moreover, due to the modifications interfering in the secure domain 101 of the smartcard 100, potential security risks occur.
Secondly, apart from additions of the hardware drivers, an additional mode of use for the smartcard 100 has to be defined which differs from the native master-slave mode. This additional mode can be used when the smartcard 100 is started out-of-terminal (so-called “standalone mode”) to respond to a user pressing the buttons 112 and to display information. This affects the architecture of the smartcard 100 system and brings additional security threat which requires additional qualification.
Thirdly, the application units 104 need to be modified to incorporate display functionality. This is difficult to achieve for well-known established and accepted standards like EMV (“Europay, Mastercard, VISA”, a standard for credit/debit financial card applications) or CEPS (“Common Electronic Purse Specification”, a standard for e-Purse Applications) and would require re-standardization.
Fourthly, the smartcard device (chip) requires to have additionally a hardware interface, namely the display interface 111, to communicate to the display 113 and to the display driver 110, respectively. Such an interface may not be desired due to security threats. U.S. Pat. No. 6,256,690 discloses a smart card comprising a microprocessor and a memory, wherein the memory stores first and second applications. The memory further comprises a memory portion designated as a message box adapted to receive a message data object from at least the first application and adapted to communicate the data message object to at least the second application. However, the architecture and communication scheme according to U.S. Pat. No. 6,256,690 has the disadvantage that security problems may occur when operating the IC card.